Yet Another Decoder is a simple droplet designed to decode MIME Base64 (including AppleSingle and AppleDouble), BinHex, MacBinary (including MacBinary III), and uuencoded files that are dropped upon it. It assumes that all segments of the original encoded document have been concatenated into the file being decoded, and that the segments are in order.
This is intended as a helper application for decoding usenet binary attachments. It is not a general purpose decoder. However, it does handle most usenet binaries fairly well, and it can deal with multiple attached files.
Yet Another Decoder is shareware. Please use the enclosed Register program to pay the shareware fee and register the program with Kagi. Information on shareware registration is at the end of this document. Yet Another Decoder may not be sold for profit or included with other software, products, publications, or services which are sold for profit without the permission of Brian Clark.
<mailto:baclark@kagi.com>
Yet Another Decoder requires System 7 or later. On older systems it will harmlessly quit. It also requires Internet Config to give decoded files the correct type and creator when the encoded file does not contain this information. The latest Internet Config should be available at:
<ftp://ftp.share.com/internet-configuration/>
The current version of Internet Config is 2.0. There were problems with file mapping before version 1.2. The recommendation is to update, deleting any old Internet Config Preferences files and the re-entering your personal settings if you used version 1.1 or have experienced mile mapping difficulties.
If Internet Config is not installed, an alert is displayed when Yet Another Decoder is launched. This alert can be disabled using the Preferences dialog (see below).
YET ANOTHER DECODER IS PROVIDED AS IS, WITHOUT ANY WARRANTY OR PROMISE OF TECHNICAL SUPPORT. BRIAN CLARK DISCLAIMS ANY LIABILITY OF ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF YET ANOTHER DECODER, INCLUDING, WITHOUT LIMITATION, INCIDENTAL, CONSEQUENTIAL, INDIRECT OR SPECIAL DAMAGES OF ANY KIND, EVEN IF BRIAN CLARK IS AWARE OF THE POSSIBILITY OF SUCH DAMAGES. BRIAN CLARK MAKES NO WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE PROGRAM, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
When performing a Base64 decode, if the program encounters a line containing name="filename.ext" or name=filename.ext or file:"filename.ext" or file:filename.ext before it finds any Base64 data, that name will be used for the decoded file. Otherwise an attempt is made to located a name for the decoded file using the Subject header line in the message. If this is unsuccessful, a name of the form untitled-nn or untitled.ext-nn will be used.
Except as noted below, Yet Another Decoder does not look for or use much of the MIME header information about an attached file that may be available. For example, it isn’t very smart about AppleDouble encoding. Most such files will decode properly, and will have the appropriate file creator, type, resources, etc., but some may not. This should rarely be a problem, since AppleDouble is not a wise choice for attachments and is seldom used for posting binaries. For better general purpose MIME decoding, use Mpack.
Setting the Type and Creator of Decoded Files
The file mapping settings of Internet Config will usually be used to assign a file type and creator to the converted file. How this is done depends on whether the file was encoded.
For a uuencoded file, there is no information available about what creator and type the decoded file should have. Therefore the type and creator will be set using the name of the decoded file and the file mapping settings of Internet Config. Some special handling is done for potential image files, however, as is described below.
Base64 encoded files may contain some clues indicating what should be the type and creator of the decoded file. If the MIME headers include information about the file type and creator (using the x-mac-type= and x-mac-creator= header strings), this information will be used. Otherwise, if there is a header of the form:
Content-type: image/image-type
where image-type is one of:
jpeg
gif
tiff
pict
then the file type and creator will use the Internet Config file mapping settings for a file whose name ends in:
.jpg
.gif
.tif
.pict
respectively. Otherwise, the actual name of the decoded file will be used in conjunction with the file mapping settings of Internet Config to set the type and creator for the decoded file, just as is done for uuencoded files. There is a preference setting to use the Internet Config creator even when a MIME creator is found: see below.
Files encoded with MacBinary, BinHex, AppleSingle, and AppleDouble all contain information about the original file's creator and type. This information is used to set the decoded file's creator and type.
Note that if the file mapping using Internet Config is unsuccessful (because you have not defined a mapping that matches the file name), the decoded file will appear to be a SimpleText (TeachText) document. You will then have to determine the appropriate file type and creator yourself, and use some other utility program (ResEdit, for example) or system extension (Get More Info, for example) to change the type and creator to the appropriate values.
Finally, for files that do not contain encoded file type information, Yet Another Decoder does a test on the first 4 bytes of each file it decodes to see if the file is probably a JPEG or GIF image file. If this seems to be the case, then the appropriate file type is assigned to the decoded file independent of the file type obtained from the filename extension and Internet Config or the file type indicated in a MIME header. This is done to deal with a weakness in QuickTime’s handling of image files: QuickTime chooses the proper decoder to use based on a file’s type and not the actual image data, and a file whose type doesn’t match the image data will fail to be properly decoded.
Comments on Uudecoding
Correctly uuencoded files should contain a line of the form:
begin nnn filename.ext
directly before the start of the uuencoded data, all on the same line. The nnn is an octal number used to set the file permissions under UNIX and similar operating systems. filename.ext is the name of the decoded file.
In some cases (typically due to an error by the encoder), the file permission number is missing. Yet Another Decoder will still recognize and decode such files.
Preferences
There are ten program preferences, set from the Preferences dialog.
1) If an error is encountered during program operation, an alert will be displayed providing the system error number and a short description of what operation failed. When “Use Notification Manager Dialog for Background Error” is checked, the Mac’s Notification Manager will display a dialog when the program encounters a problem when running in the background. Otherwise it merely blinks its icon in the application menu.
2) Yet Another Decoder allows folders to be dropped on it so that their contents can be decoded. To have any folders within a folder also processed, check the “Process Nested Folders” checkbox. Otherwise the folders and their contents will be skipped.
3) If “Skip Internet Config Not Installed Warning” is checked Yet Another Decoder will not display an alert at startup if Internet Config is not installed. The “Internet Config Extension” system extension file must be installed for YA-Decoder to be able to perform proper file creator and type mapping.
4) If “Delete Original File After Decoding” is checked, the program will delete the original encoded file after it has been processed, but only if at least one decoded output file was successfully created from the original file. Otherwise the original file remains untouched. The safest setting for this option is unchecked.
5) If “Trash Original File After Decoding” is checked, and “Delete Original File After Decoding” is not checked, the program will move the original encoded file to the trash after it has been processed, but only if at least one decoded output file was successfully created from the original file. The file will not be deleted until the user empties the trash.
6) Sometimes a single file will contain multiple attached binary files. If “Try to Decode Multiple Attachments” is checked, Yet Another Decoder will attempt to extract multiple attached files included in a single message. Because Yet Another Decoder is NOT a smart decoder, it may be that some multi-part single attachment files will not decode properly if the option to extract multiple attachments is enabled.
7) Sometimes usenet binary attachments are erroneously encoded multiple times. Sometimes a file is uuencoded twice in a row; sometimes it is first uuencoded and the Base64 encoded (or vice-versa). If “Try Recursive Decoding” is checked, Yet Another Decoder will attempt to decode again any file it successfully decodes. Note that this adds to the time it takes the program to process a file. Typically it takes half as long to process a file that does not contain any Base64 encoded or uuencoded data as it does to process a file that does contain such data. So a file that was encoded once that decodes in 30 seconds when this option is turned off will take about 45 seconds to decode if it’s turned on. A similar file that was encoded twice would take about 60 seconds to produce the final, fully decoded data.
8) The rules for BinHex encoding in multiple parts suggest that the start and end of each section of a BinHex attachment should have a special line of text that the decoding program can read and recognize. This makes decoding safer, since it's possible that a line of non-encoded text could be mistaken for BinHex data. Unfortunately, this standard may not be followed by some poorly written BinHex encoding software. By checking the "Use Lax BinHex Decoding Rules," you can tell YA-Decoder to perform less stringent checking of each line of text to determine whether it should be decoded ot not, allowing YA-Decoder to try to decode such badly formatted files.
9) MacBinary encoded and some Macintosh origin MIME Base64 encoded files, such as those in the AppleDouble format, include information for restoring the file’s creation, and modification, dates. In some cases you may want the attached binary file to have the current date as the modification date, perhaps because you have a program that watches the file’s folder for new files. If you wish for the extracted file to have a current modification date, uncheck the “Preserve Modification Date” checkbox.
10) Often MIME Base64 encoded files will have the file creator and type information specified in the MIME headers of the file. Usually this information will then be used by Yet Another Decoder to set the creator and type for the decoded file. To instead use the creator specified in your Internet Config settings, check the “Prefer Internet Config Creators” checkbox. However, as described above, probable image files will have their types assigned according to the type of image data they appear to contain, and not according to the file types specified in a MIME header.
Shareware Registration
Yet Another Decoder is shareware. If you use the program you should pay the registration fee. Doing so signals your interest in the program, encourages future development and pays for the work that has already been done.
A single user license is $15 per user. If you previously registered Yet Another NewsWatcher versions 2.2.x or 2.3.x, thank you! You do not need to register Yet Another Decoder.
Paying for Yet Another Decoder is fairly simple. Open the Register program that accompanies Yet Another Decoder. Enter your name, your email address, and the number of single user licenses you desire for each program you wish to purchase. Save or Copy or Print the data from the Register program and send the data and payment to Kagi. Kagi handles the payment processing.
If paying with Credit Card or First Virtual, you can email or fax the data to Kagi. Their email address is:
sales@kagi.com
and their fax number is:
+1 510 652-6589
You can either Copy the data from Register and paste into the body of an email message or you can Save the data to a file and you can attach that file to an email message. There is no need to compress the data file, it's already pretty small. If you have a fax modem, just Print the data to the Kagi fax number.
Payments sent via email are processed within 3 to 4 days. You will receive an email acknowledgement when it is processed. Payments sent via fax take up to 10 days and if you provide a correct internet email address you will receive an email acknowledgement.
If you are paying with Cash or Check you should print the data using the Register application and send it to the address shown on the form, which is:
Kagi
1442-A Walnut Street #392-BA
Berkeley, California 94709-1405
USA
You can pay with a wide variety of cash from different countries but at present if you pay via check, it must be a check drawn in US Dollars. Kagi cannot accept checks in other currencies, the conversion rate for non-USD checks is around USD 15 per check and that is just not practical. If you have a purchasing department, you can enter all the data into the Register program and then select Invoice as your payment method. Print three copies of the form and send it to your accounts payable people. You might want to highlight the line that mentions that they must include a copy of the form with their payment.
Kagi can not invoice your company, you need to act on my behalf and generate the invoice and handle all the paperwork on your end. Please do not fax or email payment forms that indicate Cash, Check or Invoice as the payment method. As far as we know, there is still no technology to transfer physical objects via fax or email and without the payment, the form cannot be processed.
Payments send via postal mail take time to reach Kagi and then up to 10 days for processing. Again, if you include a correct email address, you will hear from Kagi when the form is processed.
